Stop creating launch, compile, and KSP tasks at configuration time - #99

Closes #98. The Compiler Gradle plugin no longer creates the launch*SpineCompiler, compile*Java, compile*Kotlin, and ksp*Kotlin tasks by name while the projects are configured. The generate*Proto call site stays eager by design; see below.

What changed

• Launch and clean tasks are registered via sourceSets.configureEach. This replaces the eager forEach and the afterEvaluate fallback for source sets added later.
• TaskLocator (public, gradle-api) gains exists() and named(), which do not create the task. find() and get() are unchanged.

Why the issue's suggested fix could not be used as is

Gradle (9.8.2) forbids configuring other tasks from inside a lazy task configuration action. named(…).configure {}, configureEach {}, and afterEvaluate {} all fail with "… cannot be executed in the current context". So the generateProto action cannot wire the launch task lazily. The wiring now goes the other way: the launch task pulls its producer by provider.

Why generate*Proto stays eager

With generateProtoTasks.all().configureEach {}, the tests/ integration build failed with ConcurrentModificationException:

1. protobuf-gradle-plugin runs postConfigure right after the generateProtoTasks {} blocks.
2. With idea applied, postConfigure calls Utils.addToIdeSources(), which reads sourceSets.main.java.srcDirs.
3. Reading them resolves the generateProto output provider, which creates the task.
4. Our action then calls tool-base configureSourceSetDirs(), which runs setSrcDirs() on the collection being iterated.

That is the "configuration order" the old comment guarded. The comment now says so, and TaskWiringSpec has a regression test with idea applied.

Keeping this call site eager is accepted as the resolution of #98 for generate*Proto:

• Upstream: protobuf-gradle-plugin 0.10.0 itself calls generateProtoTask.get() in postConfigure whenever idea or eclipse is applied. In such builds these tasks are created during configuration whatever the Compiler does.
• Without those plugins: tool-base ProtobufSetupPlugin creates them at the same stage. Making them lazy would first require tool-base to rewrite the source-set directories per source set, outside the task configuration.
• Cost: one or two tasks per project (generateProto, generateTestProto).

Measured (./gradlew help, published .081 vs this branch)

• ksp-test functional fixture (real Kotlin + KSP plugins):
  • Before: 14 of 53 tasks created. After: 6 of 53.
  • Gone: launch{,Test}SpineCompiler, compile{,Test}Java, compile{,Test}Kotlin, ksp{,Test}Kotlin.
  • Left: generate{,Test}Proto (eager on purpose), process{,Test}Resources (tool-base#198), help, clean.
• This repo's tests/ build: the total is unchanged (169 of 219).
  • The 11 tasks this plugin used to create first are now created first by buildSrc's DokkaExts.disableDocumentationTasks (config#820).

Dependency and config updates

Later commits move the build to the releases that came out of the same effort in the other repositories.

• config, pulled twice (363fc1da, then ba47b5fb):
  • It brings the lazy buildSrc helpers of Configure tasks lazily in the buildSrc helpers config#821 and the plain jvm-tool-plugins coordinates of Point ToolBase.jvmToolPlugins to the plain plugin JAR config#822.
  • The pulls raised these pins, and they stay raised: CoreJvm .577, Validation .469, Base for build scripts .462, Time .253, BaseTypes .227, Change .209, DokkaTools .12.
  • The only pin a pull lowered, ToolBase, was set back up (see below).
• protoc-plugin POM: config#821 now declares the jar packaging for standard publications. Writing the POM fails if the publication has no main JAR.
  • The jar task of protoc-plugin has the exe classifier, so the module sets the pom packaging itself.
  • This is the packaging Gradle derived for it before; the published .081 and .082 POMs have it too.
• ToolBase .428 → .440, both version and dogfoodingVersion. .440 publishes jvm-tool-plugins and protobuf-setup-plugins as plain JARs (Publish protobuf-setup-plugins and jvm-tool-plugins as plain JARs tool-base#201).
• CoreJvm Compiler .099 → .101, both version and dogfoodingVersion. .101 no longer bundles ToolBase classes in core-jvm-plugins (Stop bundling ToolBase classes in core-jvm-plugins core-jvm-compiler#125).
  • Before, in a project applying io.spine.core-jvm, the fat JAR's ToolBase .428 classes shadowed the ToolBase the Compiler plugin declares.
  • Now every project of the tests/ build loads them from plugin-base-2.0.0-SNAPSHOT.440.jar.
• The Compiler still matches the compile task names itself instead of calling javaCompileTasksFor() and kotlinCompileTasksFor(), which ToolBase .430 added.
  • With CoreJvm Compiler .099 or older on the classpath, these calls fail with NoSuchMethodError.
  • The name matching works with any version.

For reviewers

• Changed objects in dependsOn:
  • The compile and KSP tasks now hold a TaskProvider<LaunchSpineCompiler>, not the task.
  • The launch task holds a TaskProvider<GenerateProtoTask>, not the task.
  • Code that filters dependsOn for Task instances will not see these edges. ProjectConfigSpec now resolves taskDependencies instead. No Spine sibling repo does such filtering.
• Registration-order assumption: the launch task finds its generate*Proto task by name when Gradle creates it. This relies on protobuf-gradle-plugin being applied first, which protobufExtensionOrFail() enforces. That plugin registers the task in its own earlier sourceSets.configureEach. A test covers a build that creates each task as soon as it is registered.
• Separate commit, ExcludeProtocOutputSpec: the spec passed with the protoc filter disabled.
  • Its directory was added before evaluation, so the plugin had already removed it from the source set.
  • On macOS, the /var → /private/var symlink made the asserted path differ from the reported one.
  • The spec now fails without the filter.
• Headers of touched files were updated by the repo's update-copyright hook.

Testing

• ./gradlew build dokkaGenerate passes: unit, functional, and integration tests, detekt, and Dokka. It passes again after each dependency update above, the last time with ToolBase .440 and CoreJvm Compiler .101.
• New TaskWiringSpec (12 cases) verifies that the dependencies hold and that the tasks are not created at configuration time.
  • Against the old code, the "not created", late-KSP, and late-source-set cases fail.
  • The idea case fails against the configureEach variant.
• TaskLocatorSpec has 3 new cases.

🤖 Generated with Claude Code